대각선 이동을 차단하는 위치 목록 (0,4), (9,4) 가 누락된 것 같아요! 👀
궁성 대각선은 중앙(1,4)/(8,4)과 꼭짓점만 연결하는 건데요, (0,4)는 궁성 상단 변의 중간이라 대각선 라인 위에 없거든요. 현재 코드에서 궁(General)이 (0,4)→(1,5)로 대각선 이동이 가능한 상태입니다!

누락된 부분 추가하고 테스트까지 추가했습니다!
보시다시피 이렇게 많은 조건들이 || 연산으로 이어지면 새로운 기능 추가 시 미스가 날 확률이 높아지는 것 같은데, 객체 지향적 설계가 잘못된 신호로 볼 수 있을까요?

조건 연산이 많아지는게 설계가 잘못된 신호일 수도 있고, 혹은 도메인이 복잡해서 발생하는 문제일 수도 있다고 생각해요. ㅎㅎ
해당 부분을 단위테스트로 미스날 확률을 보완하거나 조건들을 단위에 맞춰서 조건을 가지고 있는 도메인에 메세지를 날리는 방향으로 리팩터링해봐도 좋을듯 해요

누누가 정리한 MongoDB 장점 중 스키마 유연성: pieces 배열로 하나의 Document에 담을 수 있어 JOIN이 불필요라는 부분이 있었는데요, 한 가지 더 깊이 생각해보면 좋을 것 같아요.

현재 구조에서는 매 턴마다 전체 기물 배열을 통째로 교체하고 있어요.

RDBMS였다면 이동한 기물 1~2개만 UPDATE하면 되는데, MongoDB Document 구조에서는 기물 32개를 매번 전부 직렬화해서 저장하고 있거든요. 이 trade-off를 인지하고 있었나요? 현재 규모에서는 문제 없지만, Document로 한 번에 담는 게 항상 좋은 건지 생각해보면 좋을 것 같아요!

PR 설명에서 이렇게 적어주셨는데요!

트랜잭션 미지원(단일 노드): 현재 구조에서는 문제가 없지만, 게임 상태 저장이 여러 컬렉션에 걸치게 된다면 트랜잭션 관리가 RDBMS보다 까다로울 수 있다는 점을 인지했습니다

이 부분은 사실 정확하지 않아요! MongoDB는 4.0(2018년)부터 멀티 도큐먼트 트랜잭션을 지원합니다. 누누가 사용 중인 드라이버(mongodb-driver-sync:5.3.1)도 당연히 지원하고요.

// MongoDB에서도 트랜잭션이 가능해요
try (ClientSession session = client.startSession()) {
    session.startTransaction();
    collection1.insertOne(session, doc1);
    collection2.insertOne(session, doc2);
    session.commitTransaction();
}

다만 누누의 현재 구조에서는 게임 상태가 단일 Document 하나에 전부 들어가기 때문에 트랜잭션이 필요 없는 구조이긴 해요. MongoDB는 단일 Document에 대한 원자적 쓰기를 기본 보장하거든요. 그래서 replaceOne()이 중간에 실패해도 반쯤 저장되는 일은 없어요.

정리하면, 트랜잭션이 안 돼서 까다롭다가 아니라 단일 Document 구조라서 트랜잭션이 애초에 필요 없다가 더 정확한 표현이에요!

장기 도메인에 MongoDB가 정말 적합한 선택일까? 🤔

누누가 MongoDB를 선택한 도전 정신은 정말 좋았어요! 다만 솔직하게 이야기하면, 장기는 RDBMS가 더 자연스러운 도메인이라고 생각해요. 이유를 몇 가지 정리해볼게요.

장기가 RDBMS에 더 맞는 이유

• 데이터 구조가 매우 고정적이에요. 9x10 보드, 고정된 기물 타입, 고정된 팀 — 스키마가 변할 일이 없어요, 그렇기 때문에 몽고디비의 비정형 데이터를 저장하는 이점을 못누리는 상황이에요.
• 기물 이동은 1~2개 행만 변경하면 되는데, Document 구조는 매번 32개 기물을 전부 직렬화해야 해요
• "진행 중인 게임 목록", "특정 플레이어의 전적" 같은 쿼리는 RDBMS가 훨씬 자연스러워요
• 스키마 강제가 오히려 잘못된 데이터 저장을 방지해줘요 예를들면 piece_type에 오타가 들어가면 제약 조건에서 잡히니까요. 지금은 잘못 저장되면 나중에 enum 이나 다른걸로 조회할 때 캐스팅하는 과정에서 오류가 나겠죠?

MongoDB가 빛나는 도메인은

• 데이터 구조가 유동적인 경우 (예: 사용자별 설정, 로그, CMS 콘텐츠)
• 비정형 데이터가 많은 경우
• 수평 확장이 필요한 대규모 트래픽

물론 현재 미션 범위에서는 둘 다 충분히 동작하고, MongoDB를 직접 써본 경험 자체가 귀하다고 생각해요. 학습목적으로 선택한것도 이유가 되니까요!

MongoDB 에 대해 찾아보니 RDB 처럼 특정 필드만 수정할 수 있는 기능들이 존재했습니다.

//핵심 차이는 replaceOne은 _id를 제외한 문서 전체를 새 문서로 덮어쓰지만,
// updateOne + $set은 지정한 필드만 변경하고 나머지 필드는 그대로 유지한다는 점입니다.

public void update(String gameId, List<PieceDto> pieces, int turnCount) {
        ArrayList<Document> pieceDocuments = new ArrayList<>();

        for (PieceDto pieceDto : pieces) {
            pieceDocuments.add(toDocument(pieceDto));
        }

        Document updateFields = new Document("$set", new Document()
                .append("pieces", pieceDocuments)
                .append("turnCount", turnCount));

        collection.updateOne(
                Filters.eq("_id", new ObjectId(gameId)),
                updateFields
        );
    }

이렇게 하면 전체 문서를 덮어쓰는게 아니라 특정 필드만 바꾸게 됩니다.

우선, NoSQL에 관한 제 생각을 말씀드리고 싶어요.

NoSQL은 단순히 "비정형 데이터용"이라는 프레임에 가두기엔 그 철학이 더 넓다고 생각합니다.
원글에서 "Document 구조는 매번 32개 기물을 전부 직렬화해야 한다"고 하셨는데, 이는 MongoDB를 replaceOne으로만 사용한다고 가정한 것입니다.(저의 잘못된 구현ㅠㅠ) 위 코드처럼 updateOne + $set 연산자를 사용하면 특정 필드만 변경하고 나머지는 그대로 유지됩니다! 핵심 차이는 replaceOne은 _id를 제외한 문서 전체를 덮어쓰지만, updateOne + $set은 지정한 필드만 갱신한다는 점입니다. 이 부분은 제가 잘못 구현해서 오해를 드린 것 같습니다. "매번 전부 직렬화해야 한다"는 MongoDB의 본질적 한계가 아니라 사용 방식의 문제였습니다.

최근 개발자를 위한 Redis라는 책을 읽었습니다. 그 곳에서 NoSQL은 기존 RDB의 한계를 극복하기 위한 데이터베이스라는 문구를 읽은 적이 있습니다. 저 또한 RDB가 ACID를 지켜서 데이터의 일관성을 엄격히 지킨다는 점에서 장점이 많다고 생각합니다. 하지만 NoSQL은 그 엄격함을 의도적으로 완화하는 대신, 유연성과 개발 생산성이라는 다른 가치를 제공합니다. 장기 도메인처럼 스키마가 고정적이라 해도, 그 고정된 데이터를 하나의 문서로 응집력 있게 표현할 수 있다는 것 자체가 MongoDB의 장점입니다.

"고정된 스키마 = RDBMS"라는 등식에 대해서도 생각해볼 여지가 있습니다.
장기 게임 하나를 RDBMS로 모델링하면 games 테이블, pieces 테이블, moves 테이블 등 여러 테이블에 데이터가 분산되고, 게임 상태를 조회할 때마다 JOIN이 필요합니다. 반면 MongoDB는 하나의 Document 안에 게임의 전체 상태를 담을 수 있습니다. 이는 "게임 하나를 불러온다"는 가장 빈번한 연산에서 오히려 더 직관적이고 효율적인 구조입니다. 데이터가 고정적이라는 것과 데이터를 어떤 단위로 묶어서 다루느냐는 별개의 문제입니다.

스키마 검증에 대해서도 MongoDB는 대안이 있습니다.
MongoDB는 Schema Validation 기능을 제공합니다. piece_type에 오타가 들어가는 문제는 RDBMS의 제약 조건만으로 방지할 수 있는 것이 아니라, MongoDB의 JSON Schema Validation이나 애플리케이션 레벨의 enum 검증으로도 충분히 대응 가능합니다. 실제로 애플리케이션 레벨에서 검증하는 것이 DB 종류와 무관하게 더 견고한 방어선이라고 생각합니다.

몽고디비 스키마 검증 넣기
https://velog.io/@lemix777/MongoDB-%EC%8A%A4%ED%82%A4%EB%A7%88-%EC%9C%A0%ED%9A%A8%EC%84%B1-%EA%B2%80%EC%82%AC

누누가 이렇게 깊이 고민하고 답변해주셔서 너무 좋아요! 책까지 읽어보셨다니 정말 멋져요. 다만 몇 가지 짚어보고 싶은 부분이 있어서 다시 의견 남겨요.

MongoDB도 부분 업데이트가 된다는 답변에 대해

updateOne + $set을 알려주셔서 감사해요! 제가 replaceOne 기준으로만 이야기한 건 맞아요. 다만 이 답변을 읽으면서 한 가지 생각이 들었어요.

MongoDB도 RDBMS처럼 특정 필드만 수정할 수 있어요
MongoDB도 RDBMS처럼 스키마 검증을 할 수 있어요

이 답변들의 공통점은 MongoDB도 RDBMS처럼 ~할 수 있다예요. 그런데 RDBMS처럼 쓸 거면 RDBMS를 쓰면 되지 않을까요?

도구를 선택할 때 이 도구로도 X를 할 수 있다가 근거가 되면 좀 위험해요. 그럼 모든 도구가 다 같아지거든요. 진짜 생각해볼 지점은 이 도메인에서 MongoDB가 RDBMS보다 더 잘하는 게 뭔가?예요.

MongoDB의 진짜 강점은 어디서 빛나나요?

MongoDB가 정말 빛나는 시나리오는 이전에 말했듯 아래와 같아요.

• 스키마가 자주 변하는 경우 (CMS, 사용자 프로필, 로그)
• 읽기/쓰기를 분리하고 eventual consistency를 받아들이는 경우 (소셜 피드, 알림)
• 계층적 데이터를 자연스럽게 표현하는 경우 (트리, 중첩 댓글)

장기 게임은 이 중 어디에도 해당하지 않아요. 누누가 데이터가 고정적이라는 것과 데이터를 어떤 단위로 묶느냐는 별개라고 하셨는데, 그 말은 맞아요. 다만 하나의 단위로 묶고 싶다가 MongoDB를 선택하는 결정적 이유가 될 수 있는가?는 다른 문제예요.

하나의 Document로 응집이 진짜 MongoDB만의 강점인가요?

PostgreSQL의 JSONB, MySQL의 JSON 컬럼을 보면, 사실 현대 RDBMS도 하나의 row에 복잡한 JSON 구조를 담을 수 있어요. PostgreSQL JSONB는 인덱싱도 되고 부분 업데이트도 돼요.

MySql 에서 필드 자체를 json 으로 저장해서 꺼내 쓸 수도 있어요.

-- PostgreSQL에서 게임 하나를 한 row에 담는 것도 가능
CREATE TABLE games (
    id BIGSERIAL PRIMARY KEY,
    pieces JSONB NOT NULL,
    turn_count INT NOT NULL
);

UPDATE games SET pieces = jsonb_set(pieces, '{0}', '...') WHERE id = 1;

그래서 Document로 묶을 수 있다는 MongoDB의 고유한 강점이라기보다는, 모던 데이터베이스의 공통 기능에 가까워요.

Schema Validation 추가는 MongoDB의 양보라고 생각해요.

이건 좀 도발적인 표현이긴 한데요, MongoDB가 Schema Validation을 도입한 건 스키마 없는 자유로움이 실무에서 너무 많은 데이터 오염을 일으켰기 때문이에요. NoSQL의 초기 철학("스키마는 자유다!")이 실제 운영에서 한계가 있었다는 걸 인정한 거죠.

그래서 누누가 MongoDB도 Schema Validation으로 검증할 수 있다고 하신 건 맞지만, 그 기능을 쓰는 순간 RDBMS의 장점을 흉내내고 있는 것이거든요. 처음부터 RDBMS를 쓰면 그 검증이 그냥 자연스럽게 따라와요.

다시 돌아와서 NoSQL의 철학이 정확히 뭘까요?

누누가 NoSQL은 비정형 데이터용이라는 프레임에 가두기엔 그 철학이 더 넓다 하셨는데, 그 더 넓은 철학이 구체적으로 뭘까요?

제 생각에는 NoSQL의 본질적 trade-off는 CAP 정리에서 나온다고 생각해요.

• 일관성(Consistency)을 양보하고 가용성(Availability)과 분할 내성(Partition tolerance)을 얻는다
• ACID 대신 BASE를 받아들인다

장기 게임에서 이 trade-off를 받아들였나요?

• 가용성이 그렇게 중요한가? (한 사람이 하는 게임)
• 분할 내성이 필요한가? (여러 노드에 걸친 분산 처리?)
• eventual consistency가 게임에 적합한가? (턴이 살짝 늦게 반영돼도 괜찮은가?)

아니라면, NoSQL의 본질적 강점을 활용하지 않고 단지 Document 형태가 직관적이다라는 부수적 이유로 선택한 거예요. 그럼 그건 NoSQL의 철학을 따른다기보다는 JSON 저장소로 쓰는 것에 가까워요.

저는 누누의 도전 정신과 MongoDB를 깊이 공부한 점은 정말 높이 평가해요.

다만 각 도구는 자기가 잘하는 영역이 있고, 그 영역에 맞춰 쓸 때 진짜 가치가 나온다는 게 제 생각이에요. 누누가 MongoDB를 직접 써보고 그 trade-off를 체감한 것 자체가 가장 큰 학습이고, 그 경험이 나중에 이 프로젝트엔 어떤 DB를 써야 할까? 결정할 때 진짜 자산이 될 거예요!

다시 한번, 책까지 찾아보면서 답변해주셔서 정말 감사해요! 이런 깊이 있는 토론이 진짜 성장을 만든다고 생각해요 ㅎㅎ

두 메서드 모두 _id로 같은 Document를 조회하는데, 네트워크 요청이 2번 나가고 있어요. 하나의 메서드에서 Document를 한 번만 조회해서 Board와 turnCount를 같이 반환하면 어떨까요?

이걸 해결하려고 하면 Board와 turnCount를 묶어서 반환하는 객체가 필요해지는데요, 이게 사실 누누가 PR 설명에서 언급한 DTO의 자연스러운 도입 시점이라고 생각해요.

이걸 해결하려고 하면 Board와 turnCount를 묶어서 반환하는 객체가 필요해지는데요, 이게 사실 누누가 PR 설명에서 언급한 DTO의 자연스러운 도입 시점이라고 생각해요.

이 말씀이 이번 미션을 통틀어 정말 인상깊은 말 같습니다. DTO라는 새로운 도구의 도입을 언제 해야할지 고민하다가 DB가 연결되고 하나의 Document에서 필요한 데이터를 한번에 가져올 수 있도록 DTO를 도입하면 네트워크 요청도 줄일 수 있고 애플리케이션의 코드도 요청이 줄어든 만큼 데이터 호출을 위한 코드가 줄어들어 가독성이 향상되는 자연스러운 새로운 도구의 도입 지점이라는 데 공감합니다.